home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970626-19970929 / 000173_news@newsmaster….columbia.edu _Fri Aug 15 18:28:43 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA27900
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 15 Aug 1997 18:28:43 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA25441
  7.     for kermit.misc@watsun; Fri, 15 Aug 1997 18:28:42 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Turn off error detection?
  12. Date: 15 Aug 1997 22:28:35 GMT
  13. Organization: Columbia University
  14. Lines: 67
  15. Message-ID: <5t2l6j$5vi$1@apakabar.cc.columbia.edu>
  16. References: <1997Aug15.161848.25354@hrbicf>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:7478
  19.  
  20. In article <1997Aug15.161848.25354@hrbicf>,
  21. Mark T. Shirey <mts@icf.hrb.com> wrote:
  22. : We want to send a 10KByte JPEG image file over a 2400 baud half-duplex
  23. : satellite channel with a high bit error rate (1-in-1000).
  24. : 
  25. : We want speed and will sacrifice image quality.
  26. : 
  27. : Is there a graphics file format (that xv or ImageMagick can handle)
  28. : that can suffer missing or corrupted bytes and still be a viewable image?
  29. : (I'll also ask this question in a more appropriate venue if I can find one.)
  30. : 
  31. : Can C-Kermit be told to turn off all error checking? 
  32. :
  33. No.
  34.  
  35. : Or is BLOCK-CHECK 1 sufficiently lenient on, say, 8K packets
  36. : to have very few retries even in a noisy environment?
  37. : 
  38. Not really.  But I don't think that's what matters.
  39.  
  40. What you really want to do is achieve streaming and minimize retransmissions.
  41. To minimize retransmissions, pick a small packet length, thus reducing the
  42. chance that any particular packet will be corrupted and, if it is, the amount
  43. of time needed to retransmit.
  44.  
  45. At the same time, you want to minimize the turnaound delay between ACKs and
  46. NAKs.  Let's assume you are transferring from earth to earth through the
  47. satellite.  The satellite is what, 20,000 miles high?  So a signal passes from
  48. earth to the satellite in 0.1 second, and back to earth in another 0.1 second,
  49. for a total of 0.2 seconds.  A reply would take another 0.2 seconds.
  50.  
  51. The bit error rate is 1/1000, which translates to 1 byte out of 100.  So if
  52. your packet length is 100 or greater, chances are that every single one will
  53. be damaged.  So try setting the Kermit packet length to half that, or 50.
  54.  
  55. Now set the window size to (say) 30.  So a windowful of packets will carry
  56. about 1500 bytes of data, and this will take 1500 / 240 = 6.25 seconds from
  57. end to end.  So the first data packet arrives 50 / 240 + 0.2 = 0.4 seconds
  58. after it was sent, and the reply comes back about 0.2 seconds later, so even
  59. when a retransmission is requested, there is very little chance the window
  60. will fill up, and thus the sender should be able send continuously.
  61.  
  62. BUT with a packet length of 50, probably half the packets will need to be
  63. retransmitted, and then half the retransmitted ones will need to be
  64. retransmitted again, and so on.  So maybe a shorter packet would give better
  65. results.  I'll leave it to you to do the math and/or experimentation.  The
  66. tradeoffs are:
  67.  
  68.  . The shorter the packet, the greater the ratio of protocol overhead to
  69.    actual data.
  70.  
  71.  . The longer the packet, the greater the chance it will be damaged and
  72.    the more time it will take to retransmit. 
  73.  
  74. So it's like a linear programming problem with a little Monte Carlo thrown in.
  75. Some choice of packet length will maximize the troughput for this particular
  76. connection (with its speed, delay, and noise characteristics).
  77.  
  78. By the way, C-Kermit 6.0.192 tries its best to handle this sort of situation
  79. automatically, by dynamically adjusting the packet length to achieve the
  80. best throughput for the connection.  It would be intersesting to turn it loose
  81. on this one!
  82.  
  83. Finally, note that if your image data contains lots of repeated bytes (bytes,
  84. not bits), Kermit might compress it enough to make a surprising difference.
  85.  
  86. - Frank